1. Field of the Invention
This invention relates to data communications and data delivery over communication media, and, more particularly, to host computer-based data acquisition systems.
2. Description of the Relevant Art
Various types of communication mediums have been proposed for connecting external devices to computer systems. For example, two serial bus standards that have been proposed are USB (Universal Serial Bus) and IEEE 1394 (Firewire).
IEEE 1394 is an international standard, low-cost digital interface that integrates entertainment, communication, and computing electronics into consumer multimedia. Originated by Apple Computer as a desktop LAN and developed by the IEEE 1394 working group, IEEE 1394 is a hardware and software standard for transporting data at 100, 200 or 400 megabits per second (Mbps). Maximum packet sizes are 512, 1024, and 2048 bytes depending on the transfer speed. 1394 provides 64-bit addressingxe2x80x94The 16 MSb""s (most significant bits) are used for determining source/destination bus/node. As used herein, the terms xe2x80x9cnodexe2x80x9d and xe2x80x9cdevicexe2x80x9d may be used interchangeably to denote a node on the 1394 bus.
According to the IEEE 1394 standard, there can be up to 1023 buses each with up to 63 nodes. The 48 LSb""s (least significant bits) are used to access locations within a device""s addressing space. 1394 provides for Direct Memory Access (DMA). DMA is the most powerful feature of the bus for the data acquisition purposes since it allows a device to transfer data from/into computer memory without microprocessor intervention.
IEEE 1394 also defines a digital interfacexe2x80x94there is no need to convert digital data into analog and tolerate a loss of data integrity. 1394 is easy to use in that there is no need for terminators, explicit device IDs, or elaborate setup. Another benefit of 1394 is that it is xe2x80x9chot pluggablexe2x80x9d, meaning users can add or remove 1394 devices with the bus active. 1394 has a scaleable architecture, allowing users to mix 100, 200, and 400 Mbps devices on a bus. 1394 also provides a flexible topology in that it supports daisy chaining and branching for true peer-to-peer communication between 1394 devices. In addition to asynchronous data transfer, 1394 provides isochronous data transfer, which guarantees bus bandwidth and may reduce costly buffer requirements.
Serial Bus Management provides overall configuration control of the serial bus in the form of optimizing arbitration timing, guarantee of adequate electrical power for all devices on the bus, assignment of which IEEE 1394 device is the cycle master, assignment of isochronous channel ID, and notification of errors. Bus management is built upon IEEE 1212 standard register architecture. It should be noted that 1394 error notification is limited to general error detection. When an error has occurred, it may not be known when or where the error occurred, and so the delivery status of transmitted data may also be unknown.
There are two types of IEEE 1394 data transfer: asynchronous and isochronous. Asynchronous transport is the traditional computer memory-mapped, load and store interface. Data requests are sent to a specific address and an acknowledgment is returned. In addition to an architecture that scales with silicon technology, IEEE 1394 features a unique isochronous data channel interface. Isochronous data channels provide guaranteed bus bandwidth for data transport at a pre-determined rate. This is especially important for time-critical multimedia data where just-in-time delivery eliminates the need for costly buffering.
Much like LANs and WANs, IEEE 1394 is defined by the high level application interfaces that use it, not by a single physical implementation. Therefore as new silicon technologies allow high higher speeds, longer distances, and alternate media, IEEE 1394 will scale to enable new applications.
The IEEE 1394 bus was primarily intended for computer multimedia peripherals such as audio and video devices. In general, error detection and correction is not necessary for multimedia data streams, and thus error correction is not included in the IEEE 1394 standard. However, the IEEE 1394 bus has other potential applications, such as communication and control with other types of devices. One potential application for the IEEE 1394 bus is remote data acquisition, test and measurement, and industrial automation. For example, the IEEE 1394 bus could be used to connect a remote data acquisition device, measurement device, or industrial automation device to a host computer.
Certain external buses, such as Universal Serial Bus (USB), provide error detection and correction protocols within their specifications and thus are suitable for various. types of devices, including devices which receive control data. However, the use of protocols such as 1394 for providing control data to a device may be problematic in that IEEE 1394 only provides an error detection protocol. This error detection protocol is insufficient for devices, such as data acquisition (DAQ) devices, since it does not determine where the error occurred and whether the requested data has been written to the device. In many processes, such as data acquisition processes, one cannot simply repeat a read or write transaction to the device because many registers are FIFOs (First In, First Out structures) or control registers, in which repeating the transaction will either cause a glitch or inaccurate data. Therefore improved systems and methods for enabling devices which receive control data to be used with communication mediums that do not support error correction. More particularly, improved systems and methods are desired for handling device retry requests on a communication medium that does not support error correction. Further, improved systems and methods are desired for enabling instruments, data acquisition devices, and industrial automation devices to be used with the IEEE 1394 bus.
The present invention comprises various embodiments of a system and method for transferring data over a communications medium. A host computer may be coupled to a device, such as an instrument, which may be further coupled to a sensor. The instrument may be a data acquisition (DAQ) device, which combined with the sensor, may be operable to collect data concerning pressure, temperature, chemical content, current, resistance, voltage, or any other detectable attribute. The host computer may be operable to control the instrument by sending requests to read from or write to the instrument""s memory registers. The host computer may be further operable to obtain data from the instrument for storage and analysis on the host computer system. In one embodiment, the host computer may comprise a computer system, wherein the computer system is coupled to the instrument through a serial bus, such as an IEEE 1394 bus, as described in an IEEE 1394 protocol specification. In other embodiments the bus may implement other protocols such as, Ethernet, or any other serial communication protocol which does not inherently support error correction.
In one embodiment, the instrument may include a remote PCI instrument card which is coupled to a 1394/PCI bridge, such as a National Instruments FirePHLI(trademark). The 1394/PCI bridge provides translation between the IEEE 1394 protocol and PCI, allowing the host system to send 1394 requests to and receive 1394 responses from the remote PCI device.
In yet another embodiment, two such instruments may be coupled together via the 1394 bus. One instrument may be configured as a host, or master unit, while the other instrument may be configured as a slave. Each instrument may be coupled to a sensor. In one embodiment, each instrument is configured with a processor card with memory on board to execute driver software.
According to one embodiment of the invention, the host computer system generates a request to the DAQ device. The request may include a first device request to read from or write to a memory address location of the device. The first device request may include status information which indicates whether a prior device request to the memory address location of the device returned successfully.
The device receives the first device request, then examines the status information to determine if the first device request is a retry of a prior device request to the memory address location of the device. In a preferred embodiment, the status information may comprise a toggle bit which is contained in the memory address of the first device request. If the toggle bit has not been toggled, then the first device request is a retry; if the toggle bit has been toggled, then the first device request is a new request.
If the status information indicates that the device request is a retry of a prior device request, then this indicates that the host computer did not receive a valid acknowledgement to the prior device request. In this case, the host computer does not know whether the error in the prior device request occurred before the device access or after the device access. In other words, for example, the host computer does not know if the error occurred prior to the write, in which case the write was not performed to the device, or the error occurred in the acknowledgement after the write, in which case the write did complete successfully. Thus, if the status information indicates a retry, the device may determine if the prior device request completed successfully to the memory address location of the device. This is done by comparing the address and data transfer size of the first device request to those of the prior device request. If they are identical, then the prior device request did complete successfully to the memory address location of the device, and the device may ignore the retry request. Otherwise, the prior device request did not complete successfully to the memory address location of the device, and so the device may perform the retry of the prior request.
If the first device request is not a retry of the prior device request to the memory address location of the device, then the device performs the first device request, and returns an acknowledgement to the host, indicating that the first device request was completed successfully. The host determines whether a valid acknowledgement was received indicating that the first device request was completed successfully.
If the host computer system does not receive valid acknowledgement from the device, the host computer system retries the first device request. When the host computer retries the first device request, the host computer does not manipulate the status information, e.g., does not toggle the address bit, and thus the status information indicates that the request is a retry.
The host computer system completes a transaction associated with the first device request in response to the host computer system receiving a valid acknowledgement from the device, i.e. the request returning successfully. Then, a new transaction request may be received which results in a new device request being generated by the host computer system. The new device request may comprise a request to read from or write to the memory address location of the device. The host computer system may manipulate the status information in the new device request, e.g., toggle the address bit, to indicate that the first device request to the memory address location of the device returned successfully. In general, for any new device request to a memory address location (i.e. not a retry) the host computer system may manipulate the status information for that memory address to indicate that a prior request to that address location completed successfully. In one embodiment, as mentioned above, the status information may be comprised in the address of the device request, and may comprise a status bit or toggle bit, which may be toggled by the host computer system to indicate that the prior device request to the memory address location of the device returned successfully.